经常和各种bug打交道，处理多了，也就会发现有些流程在处理不同问题都会用到，套路是也。
鉴于很多流程早期容易被忽略，后续debug需重新沟通了解，造成不必要的麻烦。也因此，我有想法将这些流程整理汇总，后续debug做checklist用，同时记录下来也能不断完善改进。
1. 常规信息收集
常规信息收集主要是明确异常是问题还是feature，还是环境或用户操作异常，比如可能问题在新版本上解决了，但测试人员在旧版本上测试导致未修正。另外，低概率和远程协助debug时，现场技术型FAE可能会同时对接客户和RD，在对接RD时会有大量信息被作为常识隐含于沟通中，而这种隐含信息在对接客户时，也可能会被作为常识隐含跳过，这也就会导致一些重要的操作差异或者信息被忽略，导致一些奇怪的问题现象出现。而这往往需要耗费大量时间排查。我们沟通的首要目标就是要明确前置这些隐含信息是否为真，同时明确正确的复现条件和步骤。
当确认是一个问题时，信息收集可以了解问题复现难度、初步判定问题范围、是否新旧版本有差等，为问题处理提供早期思路。在有问题现场的时候，信息问询也能避免为盲目保护现场影响测试进度或其他问题处理开展。在人力紧张的时候，能对这个问题进行预判，排处理优先级。
就常见问题而言，主要需要收集的信息有如下，这些在做bug report时就需要详细说明，是研发人员debug的根本，也能减少和测试人员的沟通次数，提升工作效率。
- 硬件平台、软件版本、对接人，问题预期响应和实际状态，问题复现步骤、操作手法、复现概率、还原手段
- 问题现场是否还有保留，初步判定问题是哪个模块的 >>
是否需要请模块owner一起debug- 同操作对比机好坏情况，尝试复现bug，确保它确实是个bug，而不是用户或环境的error。
- 该问题是否有已修过的类似异常，可以跨软件硬件平台了解，看是否有思路可以参考。
- 同型号机器是否有好坏版本 >>
排查为新改出来的问题，也可定位可能的修改- 异常的log是否有收集
2. 问题debug
面对一个BUG，无论是否解过类似问题，我们都会有一些疑问或者假设，而这些就是我们debug首先需要厘清的和确认的。这些假设中，会有不少是我们以为一定会正确，但未经验证的，比如没有跑过测试或只在特定场景做过测试，并未在当前场景测试过的。这些想当然往往也是问题常出现的地方，因此需要我们实验验证。
Debug期间，我们要根据假设和疑点不断做实验，实验后会出现新的结论、疑问和一些冲突点，而冲突点往往指引异常的根源所在。有些时候冲突点并未能直接指引问题根源，但却可以从反面推断最初的假设和认知正确与否，是否需要重新定位问题，更换方向下手。
以本地多媒体视频播放卡顿来说，常见的debug方向无非MEMC处理、BW不足、CPU loading过重三种，这三者debug方式不尽相同，处理方式也有所差异，因此我们初步定位的方向不同，debug方式便会有所差，怀疑的点便也不同，需要关注的点也就天差地别，但当实验和假设冲突时，那就需要我们根据当下已有信息做方向转换。
- 是否有coredump文件，能否通过coredump文件回溯异常flow和问题点。log上有哪些异常，是否可以google下？
- 根据已有的信息，我们能过推断出问题出现在哪个模块，大概可能在哪些接口或流程上有问题。
- 目前疑问是什么，假设有哪些，根据此构建实验验证
- 加打印或者单元测试，定位异常位置，是输入 > 处理 > 输出
- 记录实验结论和现象，是否发现异常原因或出现新的疑点
- 重复3和4，如果未能找到原因，重新定位问题，确定是否需要更换方向。
复现规律问题。
- 必现或高概率问题，根据现象分析产生问题原因，查模块
- 低概率问题尽量多测试，找复现规律转化为必现问题以便分析
3. Rootcause确认和分析汇总
在debug出问题rootcause或者有临时措施时，需要对问题debug过程进行梳理，并整理问题的异常原因。这个过程主要目前是明确结论是否正确，问题是否解决到位，是否有其他潜在风险，同时也能存档相关处理过程，当再次遇到类似问题时，能提供这部分信息出来供借鉴和review，这对debug人也是一种复盘和提升。
- rootcause是什么？解决措施是什么？
- 解决措施是否彻底解决问题还是在客户需求内解决？是否有side effect？
- 测试建议，是否需要完整测试？单元测试？关联模块测试？场景测试？
4. 常见DEBUG工具和措施
print大法
####
4. Code Review检查
针对Rootcause做的fix，需要做专门的review，一方面避免fixer考虑不周和参吃不齐的上code质量，一方面方便后续问题追踪，code reviewer能在其他member遇到类似问题时，提供建议和思路。
在做code review之前，fixer需要做如下工作确认修改，并将相应信息提供给reviewer做参考。
- 有无本地编译过
- 有无做功能确认
- 有无side effect，可能会打到哪些模块，是否验证过
- 有无做功能开关，是否需要用项目宏隔开
- 有无多余的log需要拿掉
- 有无跨环境的lib需要确认，比如bionic和glibc是否都可编译通过并正常工作。